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This  paper  reports  on  the  usefulness  of  Nodule  for  progres¬ 
sing  the  control  of  experiments  in  e  psychoacoustic  labora¬ 
tory.  Module  was  designed  for  progressing  dedicated  cos- 
puter  systess.  As  such,  It  provides  facilities  for  sul- 
tlprograsslng  end  for  the  control  of  sachlne  dependent  dev¬ 
ices.  Using  Modula  a  non-systes  prograsser  (the  author)  was 
able  to  write  the  software  for  a  stand-alone  systes  to  con¬ 
trol  the  operation  of  a  nusber  of  concurrent  activities  in 
an  experimental  laboratory.  This  was  due  to  the  slspllclty 
of  the  language,  the  concept  of  encapsulating  Independent 
activities  in  to  separate  "nodules"  and  the  use  of  "signals" 
to  cossunlcate  anong  asynchronous  "processes”. 


INTRODUCTION 


A  oonputer  controlled  laboratory  is  essential  for 
research  in  sodern  psychoacoustics.  Precise  tlnlng 
of  conplex  waveforms  is  required,  and  the  waveforss 
thesselves  sust  be  synthesised  to  exact  specifica¬ 
tions.  The  payehoacoustic  laboratory  at  DCIEM  has 
evolved  froa  an  analogue  network  of  oscillators, 
filters,  attenuators,  noise  sources,  etc.,  in  this 
direction.  In  1979*  a  PDP-8I  which  had  been  used  as 
a  signal  generator  and  controller  was  retired  in 
favour  of  a  PDP-11/A0,  which  was  to  be  used  tc 
create  and  present  the  signals,  cossunlcate  with  up 
to  three  separate  listeners,  and  control  all  facets 
of  the  experiment. 

Using  the  PDF -8 I ,  assembly- language  progressing 
appeared  to  be  the  only  effective  method  of  perform¬ 
ing  the  required  tasks  at  an  adequate  speed.  The 
overheads,  and  sore  important,  the  possible  timing 
uncertainties  associated  with  an  operating  systes, 
sade  It  alsost  imperative  to  work  with  the  bare 
saohlne.  A  POP- 11 /AO  is,  for  sose  purposes,  a 
slower  sachlne  than  a  PDP-SI,  and  speed  of  execution 
as  well  as  tlslng  precision  are  sore  critical  in  the 
sore  oosplex  systes.  The  complexity  of  the  system 
and  the  absence  of  an  experienced  prograsser  pre¬ 
cluded  writing  in  PDP-11  assesbler  code.  On  the 
other  hand,  mono- processing  languages  like  Portran 
were  both  etabersome  as  languages  and  unsulted  for 
development  of  highly  asynchronous  concurrent  sys¬ 
tems.  Another  consideration  in  selection  of  a 
development  nethodology  was  that  the  11/AO  should 
not  be  the  development  sachlne.  The  host  sachlne 
was  an  11/3A  running  the  UNIX  tine- sharing  systes, 
which  has  a  wealth  of  software  developsent  tools, 
and  an  early  decision  was  sade  to  take  advantage  of 
those  tools. 


[1]  This  is  DCIEM  Research  Paper  No.  80-P-05 
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The  language  MODULA  was  designed  by  N.Vlrth 
(the  designer  of  PASCAL),  at  ETH  (Eldgenoesalsche 
Technische  Hochschule,  Zurich)  and  Is  described  In 
three  consecutive  articles  in  "Software-Practice  and 
Experience"  (2,  3*  A).  It  has  been  Isplemented  as  a 
cross-compiler  running  under  UNIX  for  all  types  of 
PDP-11  from  the  LSI- 11  to  the  largest  PDP-lls,  by 
the  University  of  York  (U.K.)  from  whoa  it  Is  avail¬ 
able,  with  aaintenance  and  update  services,  for  a 
nominal  fee[2].  This  implementation  was  chosen  for 
the  development  of  the  software  for  the  DCIEM 
psychoacoustic  laboratory,  partly  as  an  experiment 
to  see  how  easy  it  would  be  for  a  researcher  with  no 
systes  progressing  experience  to  develop  a  compli¬ 
cated  concurrent  real-tlse  systes.  The  results  have 
been  pleasing. 


THE  REAL-TIME  APPLICATION 

The  application  for  which  Modula  was  chosen  was  a 
systes  to  control  experiments  in  a  psychoaooustlo 
laboratory.  In  setting  up  this  laboratory  the  aim 
was  to  provide  a  facility  which  would  allow  the 
presentation  of  a  wide  range  of  auditory  stimuli  and 
the  implementation  of  many  different  experimental 
paradigms.  In  general,  our  Interest  Is  the  process¬ 
ing  of  auditory  Information  Including  speech  and 
non-speech  stimuli.  Speclflo  areas  of  Interest  are 
the  relative  advantages  of  presenting  information 
auditorily  rather  than  visually,  determining  methods 
of  improving  a  person's  capability  to  discriminate 
signals  in  noise,  end  finding  oues  used  by  humans  In 
discriminating  amongst  complex  sounds.  A  common 
pared lgm  Is  to  present  a  stimulus  or  aeries  of 
stimuli  to  an  observer  and  have  him  or  her  report  on 
the  presence  of  the  signal  or  of  a  difference 


(2]  The  address  Is  I.  D.  Cottas,  Department  of 
Computer  Science,  University  of  York,  Healing ton, 
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amongst  the  tignaU. 

Thla  rtMirch  project  la  a  continuing  one. 
Originally,  the  laboratory  for  theae  experiments 
consisted  of  a  conglomeration  of  digital  and  analog 
components  which  the  experimenter  plugged  together 
into  idiatever  configuration  waa  required  for  the 
experiment  being  carried  out  at  the  time.  Stimuli 
were  modified  by  twiddling  knoba  and  dlala,  and  data 
oolleotlon  meant  writing  down  totala  from  counters. 
Thia  kind  of  ayatea  la  prone  to  human  error  and  la 
not  eultable  for  answering  the  kinds  of  questions 
that  now  oonoern  us.  Over  time,  parts  of  the  system 
were  put  under  computer  control,  namely,  a  POP-81. 
Kith  the  SI  it  waa  possible  to  generate  simple  sig¬ 
nals  and  col loot  and  analyse  observer  responses . 
Even  so.  the  system  still  waa  Inadequate  to  oarry 
out  the  required  research,  therefore.  It  waa  com¬ 
pletely  revamped  into  the  form  shown  in  Figure  1. 
with  the  fil  being  replaced  by  an  11*10.  In  the 
design  of  the  new  laboratory,  it  was  anticipated 
that  signal  waveforms  would  be  generated  off-line 
and  passed  to  the  11/40  by  a  high-speed  link  from  a 
host  computer  (PDF- 11/3*)  for  buffering  via  EX05 
discs.  When  wanted,  the  waveform  would  be  stripped 
off  the  dlsos  and  passed  through  an  digital  to 
analogue  (d/a)  converter  to  the  audio  system.  Com¬ 
munications  between  the  observers  and  the  oomputer 
would  be  via  standard  terminals  for  maximum  flexi¬ 
bility.  gome  of  the  analog  equipment  used  previ¬ 
ously  would  still  be  required,  but  it  would  all  be 
controlled  by  the  11/40  rather  than  manually  as 
before. 
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FIGURE  i;  a  schematic  of  the  hardware 
in  the  psyoboaooustlo  laboratory. 


kith  the  change  in  hardware  there  was  a 
requirement  for  new  software.  Since  the  system  is 
entirely  oomputer  controlled,  the  amount  of  program¬ 
ming  required  and  tha  complexity  of  the  programs  to 
be  written  la  much  graater  than  before.  In  a  typi¬ 
cal  experiment,  the  computer  must  control  a  number 
of  activities  at  tha  same  time,  including  tha 
transfer  of  algnala  either  from  e  disc  or  from  tha 
boat  oomputer  to  the  11-40  and  from  there  to  the 
observer  vie  a  d/a,  tha  prasantatlon  of  visual  tim¬ 
ing  cuaa  to  tha  observer  on  a  tans  Inal,  tha  attenua- 
tlov*  of  atlmull,  tha  collection  of  responses  made, 
and  data  storage.  Up  to  three  observers  participate 
in  an  experiment  at  one  time  and  these  act iv it lea 
must  be  carried  out  for  each  observer  simultaneously 
and  independently.  Tha  software  for  such  a  system 
la  easy  neither  to  design  nor  to  write.  Tha  system 
supports  a  number  of  special  purpose  peripheral  dev¬ 
ices  to  oarry  out  the  required  eetlvltes.  Standard 
handlers  are  frequently  not  available  for  such  dgv- 
ioee  and  must  be  written.  Evan  where  standard  dev¬ 
ice  handlers  exist  they  often  cannot  be  used.  Stan¬ 
dard  handlers  are  designed  to  be  ell  things  to  all 
people  at  tha  expanse  of  spaed  of  operation.  There¬ 
fore  ,  they  are  usually  Inefficient  for  this  system 
where  many  notions  involving  many  different  peri¬ 
pherals  must  he  serried  out  in  a  brief  time  frame. 

In  summary,  the  application  waa  a  system  to 
control  tha  operation  of  an  experimental  laboratory 
with  a  large  number  of  hardware  peripherals.  Tha 
experimental  protocol  usually  involved  controlling  a 
large  number  of  virtually  simultaneous  events. 
Moreover,  since  tha  protocol  varies  considerably 
from  experiment  to  experiment  the  software  must  be 
easily  modified. 


INITIAL  MASONS  PON  SELECTION  OP  MODULE 

Given  the  complexity  of  the  ayatea  being  developed 
it  was  daelreable  that  tha  software  he  written  in  n 
higher  level  language.  This  was  doubly  important 
since  all  sf  V"  programming  was  to  be  done  by  a 
person  whose  malm  internet  won  reaearob  not  pomputer 
systems  programing.  Not  omiy  does  this  mean  a  lank 
of  expertise,  it  mine  means  that  the  system  would  he 
developed  pi ee ernes)  as  tima  permitted.  Therefore,  a 
language  use  seeded  that  would  he  simple  to  loam 
and  uas,  as  well  as  meeting  the  raquHHpente  pf  tha 
application.  In  addition,  the  plan  was  to  krita  tpa 
software  am  a  VNP  11-34  under  tha  UNIX  operating 
ayatea  in  ordnr  to  give  the  programmer  snoops  to  the 
software  tools  available  wader  W XX  and  the  hardware 
associated  with  a  large  tlmoebsro  eyetbm  (printers, 
magtapes,  largo  dines  at#.).  Thar fora,  the  language 
used  had  to  ho  aval  labia  under  UNIX,  The  alterna¬ 
tives  were  to  develop  a  system  using  the  NT-11 
operating  system  or  to  write  e  stand -alone  system 
using  either  C  or  Modulo.  Using  NT-11  meant  leerm- 
lrg  another  operating  system  es  wall  as  a  language 
in  which  to  write  the  apeolai  purpose  handlers  and 
experiments.  There  waa  also  a  distinct  possibility 
that  existing  handlers  would  have  to  be  rewritten, 
C  provided  the  capability  for  writing  a  stand-alone 
system.  However,  klrth'e  article  on  Module  <*)  sug¬ 
gested  it  waa  mare  eultable  for  this  kind  of  appli¬ 
cation. 

As  stated  previously,  Module  was  designed  for 
programming  a  dedicated  oomputer  system  suoh  ae 
those  used  in  prooess  oontrol  systems  and  experimen¬ 
tal  laboratories .  As  suoh,  it  baa  facilities  for 
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control lint  tn*  op* rot ion  of  peripheral  de vices  and 
It  la  olalmpd  to  product  highly  tffloltnt  coda* 
Modula  la  bated  on  Pa teal  and  has  aany  of  tht  con* 
struct a  found  in  that  language.  Tht  compiler 
developed  at  fork  University  in  England  for  use 
under  UNIX  aakea  it  possible  to  write  a  stand-alone 
syatea  for  a  PUP  11.  The  large  test  plan  and  the 
real-tla*  application  programs  Included  with  the 
compiler,  simplified  the  introduction  to  the 
language. 


USEFULNESS  OF  HODULA 

Modula  more  then  net  Initial  expectations.  It 
proved  extremely  simple  to  learn  to  use  and  to  write 
the  software  for  the  system.  Even  though  the 
software  was  written  over  a  apan  of  aany  months  with 
much  of  that  time  spent  on  other  projects  (including 
one  period  of  almost  two  months)!  the  time  spent  in 
relearning  was  essentially  nil.  Even  the  most  com¬ 
plex  experiment  was  straightforward  to  program 
because  of  the  capability  for  expressing  concurrency 
that  Modula  provides.  Writing  device  handlers  was 
no  more  difficult  than  programming  any  other  func¬ 
tion. 

A  detailed  description  of  the  language  is  not 
possible  here  nor  would  it  serve  any  real  purpose* 
Wlrth  provides  an  excellent  explanation  of  Modula 
and  how  it  is  used  in  the  three  articles  mentioned 
in  the  Introduction  ( 2 ,  3,  *0.  An  appreciation  of 
the  usefulness  of  Modula  is  better  achieved  by  a 
brief  description  of  some  of  the  major  constructs  in 
terms  of  how  they  were  used  in  writing  the  software 
for  this  system. 


The  Modula 

A  program  usually  consists  of  a  number  of  "modules” 
eaoh  dedicated  to  a  specific  function  such  as  I/O* 
data  storage,  signal  generation  eto.  A  module  is  a 
collection  of  procedures,  variables  and  constants 
which  are  segregated  from  the  rest  of  the  program- 
sing  environment.  They  are  declared  local  to  the 
module  and  are  not  known  to  procedures  outside  it 
unless  their  identifiers  are  deliberately  exported 
by  being  included  in  a  "define"  list.  Similarly, 
any  variables  or  routines  defined  outside  a  module 
are  not  known  inside  it  unless  they  are  Included  in 
the  module's  "use"  list.  However,  procedures  and 
processes  declared  within  a  given  module  have  access 
to  all  variables  declared  local  to  that  nodule.  In 
this  way  it  la  possible  to  have  a  number  of 
subroutines  (in  Modula  oalled  procedures)  which  have 
access  to  ooonon  variables,  yet  still  restrict  the 
scope  ,and  visibility  of  those  variables.  This 
minimises  interactions  and  simplifies  coding  of  very 
large  programs. 

Modules  can  be  nested  within  modules  making  it 
possible  to  build  functional  units  composed  of  two 
or  more  nodules.  Variables  are  shared  amongst  the 
sub  nodules  but  are  not  visible  to  the  remainder  of 
the  program.  This  makes  it  possible  to  write  a  pro¬ 
gram  as  a  collection  of  small  relatively  independent 
units.  In  fact  the  program  ltseir  la  a  module 
Identical  in  form  to  all  other  modules.  A  module 
may  in  one  application  be  the  total  program  and  in 
another  Just  perform  one  of  a  number  of  actions 
being  caused  by  another  program. 


In  writing  up  this  system  considerable  advan¬ 
tage  was  taken  of  the  module.  Instead  of  having  to 
consider  the  design  of  a  complex  program  to  run  a 
particular  experiment  it  was  only  necessary  to  con¬ 
sider  the  design  of  a  particular  functional  unit  to 
do  a  specific  task.  Initially,  a  number  of  basic 
nodules  tdiich  carried  out  specific  functions,  suoh 
as  dev lot  handlers,  were  written.  These  basic 
modules  were  then  combined  into  a  functional  unit 
that  conformed  to  a  typical  task  that  had  to  be  car¬ 
ried  out.  This  function  was  added  to  a  library  of 
functions  which  could  be  combined  to  control  any 
number  of  different  experiments  with  very  little 
additional  effort. 


Exprwlng  Concurrency  -  Ufcg  Process  jq£  Signals 
At  run  time  as  well  as  at  design  tine,  eaoh  task  la 
an  independent  functional  unit  because  of  the  capa¬ 
bility  Modula  provides  for  expressing  concurrency. 
This  makes  designing  the  system  as  a  series  of  func¬ 
tional  units  even  more  reasonable.  At  run  time 
tasks  are  each  started  in  turn  and  then  appear  to 
run  concurrently  with  one  another,  communicating  by 
means  of  shared  variables  and  "signals".  Separate 
concurrent  routine*  are  called  "processes".  A  pro¬ 
cess  is  similar  in  form  to  a  procedure  except  that 
it  runs  concurrently  with  the  routine  that  oalled 
it.  It  can  both  send  and  wait  for  signals,  and  test 
whether  anyone  Is  waiting  for  a  particular  signal. 
If  the  end  of  a  process  were  reached  It  would  not 
return  to  the  calling  routine  but  simply  go  out  of 
existence.  To  prevent  this  (a  fatal  error),  a  pro¬ 
cess  contains  a  loop  statement  without  an  exit  con¬ 
dition  (see  Figure  2)  so  that  once  it  is  initiated 
it  continues  indefinitely.  However,  it  is  not  exe¬ 
cuted  continuously.  Most  of  the  time  all  but  one 
process  will  be  waiting  for  control  to  be  paaaed  to 
it.  A  program  usually  consists  of  a  ni«ber  of 
processes  with  control  being  passed  from  one  to 
another  as  events  dictate.  Eaoh  process  oarrles  out 
a  different  task.  To  the  user  the  tasks  appear  to 
be  going  on  simultaneously. 

Control  is  passed  from  process  to  process  via 
signals.  A  signal  is  like  a  variable  exoept  that  It 
can  not  have  a  value.  In  faot  only  two  operations, 
the  procedures  ”walt(s,n)"  and  "send (a)",  and  one 
test,  the  procedure  "awaited (a)"  oan  be  applied  to  a 
signal.  The  procedure  wait(s,n)  delays  at  priority 
"n"  further  execution  of  the  process  until  the  sig¬ 
nal  "s"  is  sent  by  some  other  process.  Send(s) 
passes  control  to  a  procedure  that  has  been  waiting 
for  "s"  the  longest  or  with  the  highest  priority. 
Awaited (s)  returns  true  if  at  least  one  routine  is 
waiting  for  "s".  When  a  wait  is  encountered,  con¬ 
trol  passes  to  some  other  process  being  exeouted 
concurrently.  If  a  send  is  executed,  control  passes 
from  the  routine  with  the  send  to  a  routine  waiting 
for  the  signal.  Control  returns  to  the  sending 
routine  only  after  the  receiving  routine  finishes 
execution  of  its  code  or  another  wait  is  encoun¬ 
tered.  This  linkage  of  shifts  of  control  at  "wait" 
and  "send"  statements  means  that  Modula  Is  well 
suited  only  to  mono-processor  applications.  In  a 
multiprocessor  environment,  a  process  that  *aend*s  a 
signal  would  not  need  to  wait  while  the  concurrent 
one  began  execution. 

Part  of  the  code  for  a  process  which  oontrols 
the  timing  of  events  in  s  trial  la  shown  in  Figure 
2.  A  trial  is  broken  up  into  five  parts  -  get 


PROCESS  triaUlna; 

USE  Mtolk,  olkoff,  tUtib,  runon ,  runatrt. 
ail.  a!2,  aiovar,  raaptlna,  rtady; 


LOOP 

IP  runon  TURN 
aotolk(tlotgb[0)); 

NNILR  awaltad(raady)  00  sand(raady)  END; 
wait (olkoff);  satclk(tiatab[ 1]); 

NNILR  awaltad(sll)  00  ssnd(sll)  BN 0; 
wait (olkoff);  aotolk< tlptabf  2] ) ; 

MULE  anal  tad  (aiovar)  DO  aand(  aiovar)  RND; 
aotolk(tlatab( 1 ]);  walt(olkoff); 

NNILR  awaitad(al2)  00  aand(al2)  EM); 

♦  (•  ato  •) 

aatoXk( tlatab(3] ) ;  rasptlae:*trua; 
wait (olkoff);  raaptlns;«falso; 

ELSE  waltCrunatrt .oba)  END 

END 

END  irlalfciao; 


FIGURE  2:  An  axaapla  of  tha  coda  for 
a  prooaaa.  Otbar  prooaaaaa  and  pro- 
oaduraa  would  wait  for  tha  signals 
•ail®,  *al2*.  and  •aiovar*. 


PROCESS  playslg(oba;l«itagar); 

USE  all,  al2.  randan,  algon, 
slgoff,  runon.  runatrt; 

VAR  arlntagar; 

BEGIN 

LOOP 

IP  runon  THEN 
a:»randoa<2); 

IP  asl  THEN  wait (all .oba) 

ELSE  waltUlR.obs)  END| 
slgon(oba):  wait (aiovar, oba); 
altaf  P(  oba); 

IP  roaptlnaafalao  THEN  wait  (aiovar.  oba) 
BD8B  wait (runatrt .oba)  RND; 

ENO 

EW  playplg; 

PROCESS  raapoAaa(obailotagar) ; 

||S  raaptiao.  road,  runatrt.  runon. 


randy,  atinulua  latorvai  ona.  lntarat  Inulus  latar* 
val,  atinulua  intarval  2.  raaponaa  latorvai.  Tha 
algnal  la  praaaatad  la  ona  of  tha  two  atinulua 
intarval  a,  ona  ba  aaan  tfela  prooaaa  aata  up  a 
olook  lntarrupt  to  bappan  aona  tino  la  tha  fUtura. 
waita  for  it.  than  axaoutaa  tha  appropriata  ooda 
ralatad  to  that  nonaat  in  tina.  Thla  oftaa  laoludao 
aandins  algnala  to  othor  prooaaaaa  or  aottlng  Plata 
for  othor  prooaaaaa  to  ohaek.  Plgura  3  ahowa  two 
prooaaaaa  that  would  run  oonoiwraatly  with  trial* 
tin#.  Cownunloatlon  batwaan  thaaa  prooaaaaa  would 
ba  by  naana  of  tha  algnala  *al1*.  *al2*.  an!  "alo- 
var*  and  tha  boolaan  varUbla  *raaptino*.  Playaig 
waita  for  -all*  and  *al2"  and  *alovar*.  Hhaa  It 
raoalvaa  althar  “all*  or  *al2*  It  atarta  an  auditory 
atinulua  playing.  Whan  it  raoalvaa  "aiovar*  It  atopa 
tha  aaao  atinulua.  Raaponaa  uaaa  "raaptlna"  to 
datarui no  if  tha  naaaaga  balag  aaat  by  an  obaarvar 
waa  aant  during  tha  raaponaa  intarval.  It  la  poaal* 
bla  to  run  oora  than  ona  aubjaot.  by  atartlf*  aaoh 
prooaaa  in  Plgura  3  uora  than  onea.  Eaoh  tina  an 
lnatanoo  of  a  prooaaa  la  atartad  tha  valua  of  "aba* 
(tha  parana tar  aaoh  prooaaa  la  oallad  with)  would  ba 
dif  forant .  "Runon*  and  "runatrt"  ara  uaad  to 
aotivata  and  inhibit  thaaa  prooaaaaa  at  tha  atart 
and  flniah  af  aaoh  run. 


Providing  tha  oapablllty  to  progran  tha  handlara  far 
parlpharal  davlaaa  in  a  highar  laval  languags  la 
usually  dlffioult  baoauaa.  aa  tflrth  atataa 


•auoh  faollltiaa  ara  inharantly 
naohlna-  and  avan  oonfiguratlon- 
dapandaot  and  aa  auoh  aluda  a 
aonprahanalva  abatraot  daflnltlan." 

birth's  aolutlon  waa  to  aaolooo  tha  naohino  dspnn- 
dant  liana  lnalda  a  apaoial  typo  of  aoduls  oallad  a 
davloa  aodula  (aaa  Plgura  A). -  Tha  fbaturaa  af  tha 
davlaa  aodula  rsfloot  tha  fbaturaa  of  tha  naohlna 
tha  aanpllar  wan  writtan  far  -  In  thla  mm  a 
PDP-11.  At  tha  mm  tint  thay  ara  praatianllp 
ldantloal  in  Porn  and  was  to  standard  NadiaU  nan* 
struota.  Tharn  la  vary  llttla  aatra  to  Inara  in 
nrgor  to  writ#  a  hnadlnr  in  Ntodula.  Tha  antra 
fanturaa  ineluda  n  Mann  af  aatabllahlns  tha  prior* 
Ity  at  uhioh  a  davlaa  aparataa.  a  naana  af  providing 
aooaaa  to  hardwnra  raglatara  and  a  naana  <af  handling 
Intarrupta.  t  ,  ’ 

Tha  intagsr  nlir  at  tha  aad  af  tha  DEVICE 
NODULE  daeUratlan  la  that  davlaa 'a  priority,  dll 
praaaaaap  and  praaadurss  NtlflA  tha  davlaa  nafnlR 
aparata  at  thla  prlarUy.  Thla  naana  that  NhUa 
aada  la  halng  ppaautad  within  n  davlpn  aodula  nil 
hardwnra  or  soft  wars  Intarrupta  af  aguai  or  lawar 
priority  ara  ahalvad  until  nontrol  laovan  tha  blRh 
priarlty  aodula.  Oanaagwantly.  any  apamtiana  an  n 
davlaa  *a  raglatara  aan  ba  anrriad  nut  at  tha  aant 
priarlty  aa  tha  ralsvaat  lntarrupt. 

Tha  hardwara  raglatara  aaaaoiatad  uith  n  davlaa 
ara  alao  trantad  In  a  atmlght*farwnrd  naanar.  Bnah 
la  dafiaad  aa  a  vurlabla  Uka  any  othor  var labia, 
but  with  tha  harduatu  addrtaa  writtan  la  bmokata 
following  tha  ftdantiflar  (far  tuanpla ,  tha  daaiara* 
tlon  of  "loot ITTSbdE)  i  blta"  la  Pig  A).  Tha  ragla* 
tar  nay  ba  traatad  Ilka  any  at  bar  var  labia  and  tba 
noat  aultabla  varlabla  typo  aan  ba  uaad.  Usually, 
tba  status  rsgistsr  la  daalarad  to  ba  af  typo  "blta" 
(an  array  of  Id  boolaan  vnrlablns)  wblls  buffar 


PAR' anas tohar; 


*:V  IP  runon  THEN 
raad(oba,naaa); 

IP  raaptipn  THE 
•nowar(oba)tanoaa  END; 
ELSE  wait (runatrt .oba)  END 
END 

END  raaponaa; 


FIGURE  3:  Two  proooaaaa  that  oould 
run  oonourrantly  with  trlaltlas. 
Playaig  plays  a  signal  in  slttisr 
atinulua  intarval  on#  or  two. 
Raaponaa  waita  for  tha  obaarvara 
raaponaa  and  starts  it  in  "aass". 


DEVICE  MODULE  clock[6); 

DEFINE  tick,  time; 

VAR  tine: integer; 
tick: signal; 
lest 1775A6B] :blts; 

<•  In  Modula,  octal  constants 

ars  terminated  with  tha  character  B  •) 

PROCESS  kw  11  dock  (100B1; 

VAR  ticks: in tager; 

BEGIN 

tloka:sO; 

LOOP 

lea(6]:*true; 

<toio; 

Inc ( ticks)? 

IF  ticka*60  THEN  inc(time);  ticks :»0  END; 
sand (tick); 

END 

END  kwllclook; 

BEGIN 

time:«0;  kwllclook 
END  clock; 


FIGURE  A:  A  device  nodule  to  control 
the  operation  of  the  kwll-1  clock. 
This  aodule  only  contains  the  prooess 
to  handle  the  Interrupt.  Other  pro¬ 
cedures  that  alter  the  value  of  "lea" 
could  also  be  included*  Outside  the 
aodule  clock  "time"  is  read-only  and 
■tick"  can  only  be  waited  for. 
■Ticks",  the  tick  count,  is  invisible 
outside  the  process  kwllclook. 


registers  are  declared  to  be  type  "integer"  or 
■character".  In  this  way,  individual  bits  in  the 
status  register  can  be  nod if led  at  will,  while  the 
oontents  of  the  buffer  can  be  dealt  with  as  the 
nunbers  or  characters  that  they  truly  represent. 

The  actual  hardware  Interrupts  are  handled  In  a 
■device  process",  which  functions  in  the  sane  way  as 
any  other  process  except  that  it  will  ordinarily 
contain  a  "dolo"  Instruction.  Only  a  device  process 
can  oontaln  a  "dolo”  statement  and  only  one  instance 
of  a  device  process  can.  be  activated  at  a  time. 
Each  device  process  declaration  Includes  the  address 
of  the  Interrupt  vector  (for  example,  the  line  "PRO¬ 
CESS  kwllclook  [100B];"  In  Fig  A).  The  dolo  state¬ 
ment  Is  the  link  between  the  actual  Interrupt  and 
the  user  program.  It  acts  like  a  wait  statement, 
for  whloh  the  signal  is  sent  by  the  system  when  an 
Interrupt  happens  at  the  vector  specified  in  the 
device  process  declaration.  When  a  dolo  Is  exe¬ 
cuted,  control  is  relinquished  by  the  device  process 
until  the  proper  interrupt  occurs.  At  that  time, 
control  returns  to  the  device  process  just  as  In  any 
ordinary  Interrupt  handler,  unless  a  higher  priority 
process  is  In  execution.  Normally,  the  device  pro¬ 
cess  will  disarm  the  Interrupt,  do  Its  work,  rearm 
the  Interrupt,  and  loop  back  to  the  dolo  statement 
to  await  the  next  occurrence  of  its  Interrupt. 

The  extra  facilities  of  device  modules  are 
similar  In  form  and  use  to  the  rest  of  the  Module 


constructs.  Each  device  handler  can  be  written  as  a 
separate  unit.  Its  Internal  details.  Including  the 
operation  of  the  device  process,  are  Invisible  to 
the  rest  of  the  system. 

Writing  a  device  handier  offered  no  special 
problems,  even  though  the  writer  had  no  previous 
experience  with  device  handlers.  The  structure  that 
had  to  be  followed  was  dear  and  oonolse.  It  was 
easy  to  translate  the  specifications  in  the  hardware 
manual  into  a  device  module.  The  simplicity  of 
structure  also  meant  that  the  scope  for  error  was 
less  which  out  down  the  time  required  for  debugging 
a  routine.  Integration  of  several  device  handlers 
was  never  a  problem.  It  is  taken  care  of  by  speci¬ 
fying  a  priority  and  by  the  use  of  a  device  prooess. 
At  run  time  the  device  process  for  eaoh  device  is 
initiated.  Thereafter,  whenever  the  Interrupt  for  a 
particular  device  la  enabled,  Interrupts  to  that 
device  Are  handled  at  the  priority  specified.  Dev¬ 
ices  operate  concurrently  with  one  another  in  con¬ 
junction  with  ordinary  processes. 

The  primary  reason  for  writing  special  purpose 
handlers  was  the  inefflcienoy  of  standard  handlers. 
The  Module  compiler  is  written  with  code  efficiency 
as  a  major  design  goal.  The  test  of  this  was  the 
signal  playing  function.  Successive  samples  of  a 
waveform  are  transfered  from  a  buffer  in  core  to  the 
d/a,  one  word  at  a  time,  on  auooesalve  interrupts  of 
a  progranable  clock  which  runs  at  top  priority. 
This  buffer  ia  refilled  when  required,  from  an  RK05 
disc,  double  buffered.  If  the  clock  interrupts  hap¬ 
pen  at  too  high  a  rate  nothing  else  gets  done.  The 
Module  system  can  handle  the  dlso-to-core  transfer, 
the  oore-to-d/a  transfer,  the  clock  Interrupts,  and 
terminal  interaction  with  a  clock  interrupt  once 
every  90  microseconds.  It  is  doubtful  if  it  would 
be  possible  to  achieve  a  much  better  rate  of 
transfer  under  any  othar  system. 

In  summary,  aa  claimed  (2),  the  language  was 
well  suited  for  this  kind  of  application.  Not  only 
la  It  possible  to  write  the  concurrent  software 
required,  but  as  an  additional  benefit,  Module 
almost  seems  to  force  one  to  write  more  clean, 
elegant  and  generally  useful  software.  Writing 
functional  units  that  do  a  specific  task  ia  poten¬ 
tially  more  ueeful  end  more  flexible  than  writing  e 
total  system  right  from  tha  start.  Defining  the 
ectlons  es  separate  processes  whloh  ell  run  rela¬ 
tively  concurrently  results  In  a  program  whloh 
corresponds  more  directly  to  the  actual  operation  of 
the  experiment.  This  makes  it  easier  to  understand 
the  software  and  hence  to  debt*  it  end  to  modify  It 
later  on. 


LIMITATIONS  OF  MODULA 

The  limitations  of  Nodula  arise  mainly  out  of  one  or 
the  features  that  initially  attracted  ue  to  it; 
namely,  It  was  simple  to  learn.  Hodula  was  designed 
to  bo  ss  simple  as  possible  so  that  it  oould  rum  on 
vary  small  oomputara.  Wlrth'a  philosophy  of 
language  design  la  to  provide  aa  few  primitives  ss 
possible  for  the  job,  to  ensure  thst  these  are 
defined  in  a  natural  and  general  way,  and  to  strip 
off  ell  possible  "ormwientstlon*.  Consequently,  s 
number  of  potentially  very  useful  oonstruets  avail¬ 
able  in  most  higher  level  languages  do  not  exist  Is 
Nodule.  There  is  no  capability  for  indirect 
(pointer)  addressing,  no  inherent  file  structure,  no 


standard  I/O  commands.  no  data  type  "float” 
("real") ,  and  banco  no  floating-point  arithmetic. 
Tbs  absonca  of  I/O  commands  and  of  a  flla  structure 
la  raoulrad  by  tba  philosophy  of  Hodula.  It  la  not, 
and  doaa  not  renlace,  a  senerallsed  oparatlng  sys¬ 
tem.  It  was  daalgned  for  the  construction  of 
process-control  applications,  and  tba  aff active 
desorli£ion  of  I/O  prooaaaaa  In  a  concur rant  asyn¬ 
chronous  environment.  The  absence  of  Indirect 
addressing  la  required  by  the  strong  segregation  of 
modules .  Indirect  addressing  could  permit  nodules 
to  affect  other  modules  if  the  pointers  were 
Incorrectly  set,  resulting  In  bugs  of  great  diffi¬ 
culty  In  a  complex  concurrent  system.  The  absence 
of  Indirect  addressing  Is,  however,  annoying  when 
dealing  with  devices  such  as  a  DHC-11  (a  high-speed 
inter-computer  link),  which  asks  for  and  returns  the 
address  of  a  buffer.  It  would  save  tine  and  storage 
to  be  able  to  store  that  address  In  a  pointer  and 
pick  up  the  contents  of  the  address  by  Indirect 
addressing.  floating- point  arithmetic  is  also  very 
useful  In  many  real-time  applications.  However,  It 
Is  also  very  time  consuming  If  there  Is  no  floating 
point  hardware  on  the  machine.  Therefore  In  many 
applications,  such  as  this  one,  It  oould  not  be  used 
whether  It  was  available  or  not.  Nevertheless,  pro¬ 
vision  of  a  "float"  data  type  would  probably  be  one 
of  the  most  useful  extensions  of  Hodula. 

The  small  number  of  constructs  limit  the  range 
of  applications  for  which  Hodula  la  useful.  It  Is 
not  a  general  purpose  language.  This  was  noted  by 
Holden  and  Hand  (1)  in  their  aasesment  of  Hodula. 
They  felt  that  Hodula  was  most  useful  for  the 
development  of  small  real-time  systems  written  by  a 
single  programmer.  It  would  not  be  possible  to 
write  a  general  operating  system  In  Hodula  beoause 
It  does  not  allow  pre-emption  which  Is  necessary  to 
implement  a  scheduler.  Since  what  it  does.  It  does 
well,  it  Is  worth  learning  Hodula  to  write  the 
software  for  a  small  real-time  system. 


THE  COMPILER 

The  amount  of  use  a  language  gets  on  s  particular 
system  usually  depends  on  the  quality  of  the  com¬ 
piler  written  for  that  system.  The  Implementation 
used  in  this  application  was  Release  2.0  of  the 
University  of  lork  (01)  Module  compiler.  This  com¬ 
piler  Is  written  In  BCPL,  and  can  be  built  on  a 
PDP-11  running  UNIX,  or  on  s  DEC-10  or  DCC-20.  It 
runs  under  UNIX,  and  produces  code  for  any  bare 
PDP-11,  from  an  LSI- 11  to  an  11/70.  Normally,  the 
target  machine  will  be  one  of  the  smaller  PDP-11 'a. 
There  is  a  possibility  that  versions  far  DEC  operat¬ 
ing  systems  on  the  PDP-11  will  be  available. 
Release  3.0  la  expected  to  be  available  on  UNIX  in 
Spring  I960.  The  PASCAL  User's  Group  Newsletter 
lists  other  Implementations  of  Hodula,  with  various 
target  machines,  and  running  on  various  hosts. 

Our  experience  with  the  York  compiler  has  been 
mainly  favourable.  To  start  with,  It  was  easy  to 
Install.  It  compiled  and  ran  on  the  first  attempt. 
This  Included  compilation  of  all  the  BCPL  souroe 
code  using  a  binary-only  BCPL  compiler  supplied  with 
the  Hodula  system.  The  compiler  includes  a  large 
test  plan  (about  150  pages  of  Hodula  oode)  to  oheek 
out  each  of  the  constructs  of  the  language.  This 
has  proved  of  Inestimable  value.  It  shows  clearly 
by  example  how  to  use  eaoh  construct  and  what  hap¬ 
pens  When  you  do;  It  provides  many  examples  of  ways 


to  code  Interesting  functions  and  processes;  ana  it 
proves  that  the  compiler  la  working  reasonably  reli¬ 
ably.  This  last  feature  la  a  great  psychological 
aid  when  program  bugs  appear.  You  oan  believe  that 
the  bugs  are  your  own  fault  rather  than  the  fault  of 
the  compiler.  This  belief  has  so  far  been  well- 
founded.  There  are  a  few  known  oompller  bugs,  for 
which  fixes  are  available  from  the  University  of 
York  as  part  of  the  maintenance  service,  but  these 
bugs  seldom  appear.  When  they  do,  It  Is  usually 
obvious  that  there  is  a  oompller  bug  rather  than  a 
program  bug. 


CONCLUSION 

Writing  a  stand-alone  system  for  an  experimental 
laboratory  la  not  a  simple  task,  no  matter  what  the 
language.  The  requirements  are  stringent  and  usu¬ 
ally  the  work  la  never  completed,  as  the  uses  for 
the  system  are  constantly  shifting.  With  Hodula  the 
task  seemed  more  reasonable.  It  was  written  for 
this  kind  of  application.  Consequently,  one  does 
not  have  the  problem  of  adapting  oonstruets  to  fit 
one's  needs.  Rather  the  oonstruets  seem  to  assist 
In  the  definition  and  design  of  the  system.  The 
result  is  that  It  la  possible  for  a  non-system  pro¬ 
grammer  to  design,  write  and  debug  a  stand-alone 
system  and  produce  software  that  la  easy  to  read, 
flexible,  efficient,  and  easy  to  modify  at  a  later 
date. 
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